I haven't reviewed the changes yet, but I support moving to Traitlets. It'll help with adding extensibility, which has been discussed in a few issues including:

• Support custom culling logic through hooks (like Spawner's pre_spawn_hook etc) #25
• How configurable should the culler be? #9

Since we can let people install their own extensions, and initialise them in jupyterhub-idle-culler by passing the parent object to them.

Absolutely love it!

This... looks ready to go? What else is missing?

@yuvipanda I marked this as draft because I threw it together in a hotel lounge while on travel and then haven't been able to get back to it. But I thought it might be helpful to at least get a version of it out there as a proposal for people to look at and see if there was anything obviously missing in terms of making sure the CLI looked compatible with the old one, etc.

I did have a question about logging and I see #84 has popped up, related. We could try to reconcile that here or do it as a later pull request (one thing at a time...?). In any case I am interested in whether folks think this is a better move than going with argparse. I think traitlets has the upside of configuration and familiarity within the JupyterHub domain.

We don't need to do everything in one go as long as we don't introduce any major problems, and resolve any issues before a release. I'm in favour of getting this in and dealing with logging in a separate PR.

What was bothering me here ended up just being the default log level when you switch to traitlets is warning, not info (which is what idle culler was using before). Leaving that be just didn't sit right with me, and it was fairly simple to just make the traitlets logging work so I went ahead with that. Sorry for the hold up.

Should address #84

I recently came across some logging issues that seem similar to problems resolved by this PR.

@manics @yuvipanda I'd almost forgot I did this. Are we happy with this?

I've created 2i2c-org/infrastructure#5465 so if nobody else gets to review / merge this before the next 2i2c sprint starts (this coming wednesday), someone will be assigned to review this work that sprint! 2i2c-org/infrastructure#5058 has more info :)

@rcthomas thank you for this PR! It's good to see us moving towards traitlets in another Jupyter project.

@sgibson91 and I took a look at this today. Whilst we think it's mergeable, we had a couple of questions that we'd like to resolve before merging:

1. This script cannot be run without installing traitlets or a Jupyter package (which pulls in traitlets). Is this intentional, or do we need to update pyproject.toml?
2. The URL trait defaults to None (from os.environ.get), but the trait does not set allow_none. It seems clear that the intention is for url to be a required argument. Is it possible to improve the user experience of failing to define --url, which presently raises a somewhat-obscure validation error?
3. JupyterLab uses --config for the config_file alias. Is it worth unifying with JupyterLab here?

Thanks!

1. That's an oversight on my part. Indeed, traitlets is now required and needs to be added to pyproject.toml.
2. Hmmm! If you want the traitlets version to reproduce the behavior of the Tornado options version, the right move is to set allow_none since I think the Tornado options version allows for that to be None. Then it propagates to the same place (first fetch() call) in either version and results in the same error. That said, the url parameter is needed for the service to run.
3. Makes sense, let's go with --config instead of --config-file for that alias.

Thanks, @agoose77

@agoose77 @sgibson91 I've added 4 commits to address your feedback. The additional commit includes listing the --config option in the README. I did follow the logic that the failure mode should be the same as with tornado.options if --url is unspecified. Let me know what you think.

cc @ClaytonAstrom: Heads up that --config-file is going to be --config 😄

@yuvipanda please can you merge this when you get a chance? :)

Thank you very much for the PR and patience, @rcthomas! And thanks for the review, @agoose77 and @sgibson91 :)